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1,0  Introduction/Background 

Space  Communications  Protocol  Standards  (SCPS)  is  a  joint  DOD  (SMC/AXE  Maj. 
Cole,  SMC/ADC  Lt.  Capizzi),  NASA  (Adrian  Hooke,  JPL)  and  NS  A  (Capt.  Vasko)  program. 
The  DOD  portion  of  this  effort  was  originally  managed  by  USSPACECOM/J4P.  Responsibility 
for  the  DOD  portion  was  transferred  to  the  Space  and  Missile  System  Center  (SMC)  during  the 
latter  part  of  FY96. 

The  MITRE  Corp.  functioned  as  system  engineer  providing  software  integration,  protocol 
development,  test  plans,  procedures  and  reports,  and  user  interface.  The  software  developers 
included  MITRE  (SCPS-TP  and  SCPS-NP),  SAIC  (SCPS-FP)  and  SPARTA  (SCPS-SP). 
Validation  was  handled  by  the  Joint  Interoperability  Test  Center  (JITC). 

The  foeus  of  SCPS  is  to  develop,  test  and  validate  four  upper  layer  eomputer  network 
protocols.  The  application  layer  SCPS-FP  (File  Protocol),  transport  layer  SCPS-TP  (Transport 
Protocol),  layer  3.5  SCPS-SP  (Security  Protocol)  and  network  layer  SCPS-NP  (Network 
Protocol)  were  developed  under  this  joint  effort. 

Historically,  data  transmission  protocols  have  been  developed  with  fixed  ground 
application  in  mind  (Example:  TCP,  IP,  and  FTP).  Space  applications  exists  in  a  different 
operational  environment  relative  to  fixed  ground  application.  Factors  that  make  the  space 
environment  different  are  constrained  bandwidth,  higher  Bit  Error  Rate  (BER),  dynamic  links, 
higher  link  delay  and  limited  computing  power  onboard  the  space  vehicle.  The  SCPS  protocol 
suite  was  developed  to  better  couple  the  data  transmission  protocols  to  the  spaee  environment. 

This  report  will  cover  AFRL/IFGC  support  for  SCPS-FTP,  SCPS-TP  and  SCPS-NP 
testing  for  the  period  05/97  -  10/97.  As  system  engineer  MITRE  made  the  decision  to  utilize  the 
extensive  networking  and  satellite  communication  facilities  and  expertise  resident  at 
AFRL/IFGC.  Prior  to  testing  at  AFRL,  SCPS  was  tested  using  a  lab  simulation  test  bed.  Other 
SCPS  tests  include  the  M22  bent-pipe  flight  test  (12/95)  and  STRV  TT&C  flight  tests  during  the 
period  (01/96  -  04/96). 

2.0  What  is  SCPS? 

The  Space  Communications  Protocol  Standards  is  a  collection  of  four  integrated,  layered 
protocols  which  are  designed  to  operate  over  existing  space  Telemetry,  Telecommand  & 
Communication  (TT&C)  charmels.  The  standard  Consultative  Committee  for  Space  Data 
Systems  (CCSDS)  and  the  Link  layer  or  Space  Ground  Link  Systems  (SGLS)  are  examples  of 
TT&C  channels.  These  channels  are  specified  in  a  set  of  CCSDS  recommendations. 

The  File  Protocol  (SCPS-FP)  operates  at  the  highest  layer  (Application  Layer  7)  in  the 
International  Standards  Organization  (ISO)  Open  Systems  Interconnection  (OSI)  reference 
model.  The  SCPS-FP  is  a  "tuned  up"  version  of  the  Internet  File  Transfer  Protocol  (FTP). 
SCPS  has  been  optimized  to  operate  more  efficiently  in  space.  SCPS  provides  certain  new 
services  that  are  required  by  space  missions  (such  as  the  ability  to  manipulate  individual  records 
without  reloading  the  whole  file). 

The  SCPS-FP  is  interoperable  with  commercial  FTP.  The  "Non-interaetive  File  Transfer 
Protocol"  (SCPS-NiFTP)  is  a  variant  of  the  SCPS-FP  that  is  also  under  development.  This  new 
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protocol  is  not  FTP-interoperable  but  can  tolerate  long  propagation  delays  without  the  need  for 
time-eonsuming  handshaking  between  space  and  ground  nodes. 

Transport  Protoeol  (SCPS-TP)  is  a  modified  version  of  the  Internet  Transmission  Control 
Protocol  (TCP)  and  the  User  Datagram  Protocol  (UDP)  operating  at  the  Transport  Layer  (OSI 
Layer  4).  TCP/UDP  generally  does  not  perform  well  in  stressed  environments  typieal  of  space 
missions  (i.e.,  networks  with  high  link  error  rates  not  simply  related  to  congestion,  asymmetry  or 
imbalanee  between  forward  and  return  channel  eapaeities,  long  propagation  delays  and 
interrupted  connectivity).  SCPS-TP  provides  reliable  end-to-end  delivery  of  spacecraft 
command  and  telemetry  data  over  a  network  containing  one  or  more  unreliable  spaee-ground 
eommunieation  channels. 

It  also  includes  a  mixture  of  extensions  to  eurrent  TCP  features.  TP  provides  window 
scaling  to  handle  long  delays  and  high  volumes  of  in-transit  data,  seleetive  aeknowledgment  and 
header  compression,  and  "best  effort"  service  that  eontinues  to  deliver  data  even  if  the 
acknowledgment  channel  becomes  temporarily  unreliable.  Its  implementation  has  been 
customized  to  minimize  communieations  overhead  and  to  fit  into  resource-limited  space  systems. 
A  non-interactive  variant  of  the  SCPS-TP  is  currently  being  considered  for  very  long  propagation 
delay  environments  where  an  aeknowledgment  path  effectively  does  not  exist. 

The  Security  Protocol  (SCPS-SP)  is  an  optional  data  protection  mechanism  which 
provides  selectable  levels  of  end-to-end  security  (e.g.,  message  authentieation,  access  control, 
integrity  and  encryption)  and  is  slotted  between  the  Transport  and  Network  layers  (OSI  Layer 
3.5). 

Network  Protocol  (SCPS-NP)  at  the  Network  layer  (OSI  Layer  3)  provides  fimctionality 
similar  to  the  Internet  Protocol  (IP).  IP  has  been  customized  to  support  unique  routing 
configurations.  SCPS-NP  has  been  "shrunk  down"  for  space  networking  applications  and 
provides  for  flood  routing  through  constellations  of  spaceeraft,  which  are  characterized  by  fewer 
nodes  relative  to  global  networks.  This  is  to  minimize  overall  eommunications  overhead. 

The  SCPS-NP  can  operate  in  a  connection-oriented  (eireuit-switehed)  mode  similar  to  the 
current  CCSDS  "Path"  service,  or  it  can  support  connectionless  (packet-switehed)  IP-like 
routing.  It  is  a  fully  scaleable  protocol,  whose  features  (and  therefore  overhead)  are  seleetahle  to 
mateh  the  application.  Address  sizes  can  range  from  no  address  all  the  way  to  IP  Version  6. 

In  general,  Internet  protocols  such  as  TCP/IP  (including  FTP  and  UDP)  are  designed  to 
maximize  performance  and  economy  for  terrestrial  networks.  Their  approaeh  to  retransmission, 
recovery  and  time-outs  is  inappropriate  for  space  applications.  Current  CCSDS  Paeket 
Telemetry,  Teleeommand  and  Advance  Orbiting  Systems  (AOS)  protoeols,  while  an 
improvement  over  TCP/IP  for  space  applications,  focus  primarily  on  basic  data  transfer.  The 
SCPS  protocols  extend  this  capability  to  more  sophisticated  spaee-speeific  needs  sueh  as  the 
ability  to  eombine  eommand  and  telemetry  data  into  recognizable  files  and  transport  them  aeross 
the  space-ground  data  network  with  end-to-end  reliability  and  seeurity. 

The  design  of  the  SCPS  suite  of  protocols  is  driven  by  several  characteristics  of 
modern-day  space  missions.  Modern  satellites  provide  enhanced  onboard  processing.  The  need 
to  eommunieate  critieal  data  reliably  is  always  a  consideration,  even  in  the  faee  of  link  failures. 
The  need  to  effieiently  trade  off  buffer  use,  reliability  and  message  delay  is  critieal.  To  automate 
control  and  reduce  ground  support  infrastructure  is  highly  desired. 

The  SCPS  protocols  may  operate  as  an  integrated  (OSI  Layers  3-7)  stack  or  be 
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individually  selected  to  match  a  particular  application  (e.g.,  running  the  File  Protocol  directly 
over  an  inherently  reliable  link  layer  such  as  CCSDS).  In  general,  they  have  been  designed  for 
an  environment  in  which  one  end  of  a  data  transfer  is  on  the  ground  and  the  other  end  is  hosted  in 
a  satellite  onboard  processor  with  relatively  constrained  CPU  and  memory  capabilities  and  where 
communication  bandwidth  is  at  a  premium.  The  code  implementations  are  therefore  deliberately 
"skinny"  (i.e.,  sparse  or  spare)  and  operate  with  high  data  transfer  efficiency.  Though  designed 
initially  for  traditional  spacecraft  telemetry  and  telecommand  applications,  many  of  the  protocol 
features  have  the  potential  for  useful  commercial  application,  including  high  rate  data  transfer 
through  noisy,  long  delay  satellite  channels. 

In  conclusion,  SCPS  was  developed  for  space  applications  which,  as  such,  exist  in  a 
different  operational  environment  relative  to  fixed  ground  applications.  In  a  space  environment 
constrained  bandwidth,  higher  BER,  dynamic  links,  higher  link  delay  and  limited  computing 
power  onboard  space  vehicles  require  a  more  robust  protocol  suite  such  as  SCPS.  SCPS  is  also 
applicable  to  tactical,  ground  mobile  and  ground/air  environments.  SCPS  provides  considerable 
improvement  over  TCP,  IP  and  FTP  for  all  these  environments.  The  SCPS-TP  window  scaling 
option  addresses  large  delays.  The  Negative  ACKnowledgement  (NACK)  option,  and  “The  best 
effort  transport  service”  reduced  processing  overhead  and  utilize  bandwidth  efficiently  while 
improving  BER  performance.  SCPS  header  compression  reduces  packet  overhead  and  better 
utilizes  bandwidth.  SCPS  is  also  responsive  to  link  corruption  and  /or  outage,  not  just  traffic 
congestion.  SCPS  NP  relative  to  IP  supports  connection  oriented  addressing.  This  is 
advantageous  for  fixed  configurations  such  as  GEO  satellites.  SCPS-IP  allows  various  routing 
algorithms  such  as  flood,  dual-path  and  others.  SCPS-IP  also  supports  packed  precedence 
important  in  DOD  applications.  SCPS-FP  gets  file  size  prior  to  transfer  to  determine  if  full  file 
can  be  transmitted.  This  is  more  efficient  for  dynamic  short  duration  links.  SCPS-FP  supports 
update  of  individual  recofds  thus  making  better  use  of  bandwidth  and  improving  efficiency. 
Automatic  restarts  for  file  transfer  supports  link  reconfigurations  such  as  LEO  contacts.  SCPS- 
FP  supports  file/record  error  checks  for  true  E/E  error  detection.  These  factors  make  SCPS  a 
standardized  solution,  for  space  applications,  which  provides  improved  performance  relative  to 
fixed  ground  based  data  transmission  protocols. 

3.0  Test  Configurations 

Two  distinct  test  configurations  were  required  to  complete  the  SCPS  test  plan.  Test 
configuration  1  supports  SCPS-TP  and  FP  testing  while  test  configuration  2  supports  SCPS-NP 
testing.  All  testing  was  conducted  over  the  NASA  Advanced  Communications  Technology 
Satellite  (ACTS).  The  ACTS  satellite  at  present  is  a  one-of-a-kind  resource  in  that  it  operates  in 
the  Ka  band  of  the  RF  spectrum.  This  band  utilizes  the  29-30  GHz  frequency  on  the  uplink  and 
19-20  GHz  on  the  dovralink.  The  Ka  band  is  much  higher  in  frequency  than  the  present 
commercial  bands  such  as  the  C,  X,  and  Ku  bands.  This  makes  it  more  susceptible  to 
atmospheric  conditions  such  as  clouds  and  rain.  It  thus  provided  for  a  more  rigorous  testing  of 
the  SCPS  protocols  in  that  they  had  to  compensate  for  a  wider  variation  in  Channel  parameters, 
and  bit  error  rates  and  patterns  than  would  have  been  present  if  the  testing  had  been  conducted 
over  leased  commercial  or  DOD  satellite  channels.  The  Rome  Research  Site  (AFRL/IFGC)  was 
chosen  as  the  SCPS  test-bed  location  because  of  the  existence  of  an  ACTS  ground  terminal 
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shelter  at  the  site  and  Rome's  ability  to  obtain  sole  user  status  on  the  ACTS  satellite  for  the 
extended  time  periods  required  for  the  SCPS  testing.  This  allowed  for  unlimited  flexibility  in 
terms  of  channel  bandwidth  and  separation,  and  the  ability  to  completely  control  transmitted 
power  so  that  bit  error  rates  (based  on  Eb/No)  could  be  adjusted  and  maintained  at  desired  levels 
for  any  given  test  segment.  This  control  was  absolutely  necessary  to  evaluate  protocol 
performance  under  different  channel  conditions.  The  test  configuration  at  Rome  also  allowed  for 
the  provision  of  a  full  duplex  link  while  keeping  the  entire  test-bed  within  a  single  location.  The 
test  was  therefore  functionally  identical  to  having  two  LANs  separated  by  a  geographic  distance 
as  great  as  could  be  covered  by  the  footprint  of  a  given  satellite  (i.e.  100  to  1000  miles).  This 
was  accomplished  by  configuring  the  two  modem  and  router  sets  (for  LANs  1  and  2)  to  operate 
through  a  single  RF  up  and  down  conversion  stage  (and  a  single  1.8  meter  satellite  dish)  while 
transmitting  on  two  widely-spaced  IF  frequencies  out  of  the  modems.  Each  of  the  LANs  was 
connected  via  its  own  fiber  optic  cable  pair  (from  inside  the  AFRL  Network  Communications 
Lab  in  Bldg.  3)  to  the  modems  which  were  collocated  with  the  satellite  terminal  near  the  South 
side  of  the  building. 

3.1  Test  Configuration  1 

Unique  to  SCPS-TP  and  SCPS-FP  testing  is  test  configuration  1  shown  in  Figure  1  which 
was  established  at  AFRL/IFG  specifically  for  the  testing  activity.  Configuration  1  provides 
connectivity  between  LAN-1  and  LAN-2  via  the  ACTS  satellite.  Only  one  Ka  band  satellite 
terminal  is  required  because  its  bandwidth  is  wide  enough  to  provide  a  dual  full  duplex 
capability. 

The  workstations,  labeled  WSl,  WS3  and  WS4,  are  IBM  PC  clones  employing  the 
FreeBSD  2.1.6  operating  system.  These  workstations  make  up  LAN-1,  the  source  side  of  the 
link.  Each  workstation  supports  two  Ethernet  cards  which  provide  connectivity  to  LAN-1  and 
the  Rome  Laboratory  Computer  Network  (RLCN)  Ethernet.  This  allows  isolation  for  LAN-1 
and  at  the  same  time  remote  access  to  control  test  functions.  Remote  control  of  modem  ftinction 
is  provided  via  the  RS-232  interface  of  the  router,  which  is  attached  to  LAN-1.  This  allows  the 
transmitted  power  on  the  satellite  uplink  to  be  controlled  from  a  terminal  on  the  LAN.  This 
transmitted  power  is  adjusted  to  set  the  bit  error  rate  (BER)  for  any  given  protocol  test.  After 
changing  transmit  power  the  link  error  rate  is  verified  by  running  the  bit  error  rate  tester  (BERT) 
function  built  into  the  modems  prior  to  each  new  protocol  test  period.  The  Transmit/Receive 
data  path  between  the  modem  and  the  router  is  provided  via  the  router  RS-449  interface.  This 
provides  for  the  flow  of  data  between  LAN-1  and  LAN-2  via  the  satellite  link.  Workstation  WSl 
hosts  TCP/IP,  SCPS-TP/IP,  SCPS-FP/SCPS-TP/IP  and  test  drivers.  Workstation  WS3  is  the 
congestion  traffic  generator.  Workstation  WS4  is  the  LAN-1  traffic  monitor. 

LAN-2,  the  destination,  is  configured  identical  to  LAN-1  except  that  LAN-2  employs 
only  one  FreeBSD  workstation  WS2.  WS2  hosts  TCP/IP,  SCPS-TP/IP,  SCPS-FP/SCPS-TP/IP 
and  test  drivers.  The  satellite  link  data  can  flow  freely  between  LAN-1  and  LAN-2  all  under 
remote  control  via  WS7  the  test  controller.  WS7  is  configured  similar  to  the  other  workstation 
and  provides  access  to  both  LAN’s  via  the  RLCN  Ethernet. 
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Figure  1.  Test  Configuration  1 
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Figure  2.  Test  Configuration  2 


3.2  Test  Configuration  2 


Test  configuration  2,  as  shown  in  Figure  2,  is  unique  to  SCPS-NP  testing.  This 
configuration  is  similar  to  test  configuration  1,  and  thus  only  the  differences  will  be  described 
here. 

For  both  LAN-1  and  LAN^2  the  routers  that  provide  the  data  and  control  functions 
between  the  LAN’s  and  the  modems  are  replaced  with  IBM  PC  clones  (WS5  and  WS6)  running 
the  FreeBSD  operating  system.  The  workstations  WS5  and  WS6  are  configured  to  be  SCPS-NP 
routers.  RS-449  interface  cards  were  inserted  in  the  workstations  so  their  hardware  functionality 
is  identical  to  the  routers  in  test  configuration  1.  This  setup  can  provide  SCPS-TP/SCPS-NP 
over  the  satellite  link.  Over  the  LAN’s  SCPS-TP/SCPS-NP  encapsulated  in  IP  is  used. 

4.0  Test  Procedures 

The  focus  of  SCPS  testing  was  to  define  the  performance  of  SCPS-TP  in  terms  of 
comparison  to  the  current  standard  (TCP).  A  number  of  parameters  effect  the  performance  of 
SCPS-TP  relative  to  standard  TCP.  Factors  considered  are  size  of  the  file  being  transferred, 
packet  size,  buffer  size,  network  congestion  and  communications  link  corruption.  All  these 
factors  come  into  play  when  we  consider  networks  containing  wireless  communication  links. 
Wireless  networks  are  subject  to  bandwidth  constraints,  and  periods  of  poor  BER  performance 
and  outages. 

4. 1  Congestion  and  Corruption 

TCP  was  designed  to  interpret  lost  packets  as  a  sign  of  congestion  on  the  network.  While 
this  is  a  good  assumption  for  terrestrial  networks,  it  is  not  appropriate  for  networks  depending  on 
wireless  communication  links.  Networks  depending  on  wireless  communications  can  be 
degraded  by  poor  signal  to  noise  ratio  leading  to  poor  BER  performance.  This  is  not  usually  the 
case  with  terrestrial  networks.  We  refer  to  a  degraded  communication  link  as  being  corrupted  as 
opposed  to  a  terrestrial  network  that  becomes  congested.  In  both  cases  the  result  is  lost  packets. 
It  is  clear  that  the  best  way  to  deal  with  lost  packets  is  dependent  on  whether  the  network  is 
congested  or  corrupted.  SCPS-TP  is  capable  of  detecting  corruption  and  responding 
appropriately.  This  means  that  SCPS-TP  will  out  perform  standard  TCP  in  networks  containing 
corrupted  commimication  links. 

4.2  Satellite  Link  Delay 

If  a  network  contains  satellite  communications  links  then  long  link  delays  will  result. 
This  delay  is  noticeable  for  all  types  of  long  distance  links,  but  is  particularly  evident  with 
geosynchronous  satellites  (such  as  ACTS)  where  the  link  distance  is  on  the  order  of  50,000  miles 
with  a  corresponding  transmission  delay  of  250  milliseconds  per  satellite  hop.  TCP  suffers 
severe  performance  loss  in  the  presence  of  such  delays.  SCPS-TP  was  designed  to  handle  the 
long  delays  and  respond  appropriately.  The  size  of  the  file  being  transferred,  packet  size  and 
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buffer  size  were  varied  during  the  test  to  accentuate  the  ability  of  SCPS-TP  to  deal  with  long  link 
delays. 

5.0  Test  Results 

The  SCPS  protocol  suite  was  tested  under  both  a  corrupted  and/or  a  congested  link 
envirorunent.  A  corrupted  link  is  when  the  BER  on  the  channel  is  high  (one  error  in  a  million  or 
worse).  A  congested  link  results  in  degraded  performance  due  to  a  large  number  of  users  and/or 
heavy  traffic  over  the  link.  Other  parameters  that  effect  SCPS  performance,  such  as  data  rate 
over  the  link,  size  of  the  file  being  transferred  and  packet  size,  were  also  evaluated. 


5 . 1  Corrupted  Link 

Figure  3  shows  the  performance  of  TP,  with  and  without  congestion  control,  as 
compared  to  standard  TCP.  The  improvement  of  TP  over  standard  TCP  is  quite  remarkable  for 
links  with  a  BER  greater  than  one  in  a  million.  The  data  shows  that  even  with  congestion  control 
turned  on,  TP  still  out  performs  TCP  in  a  corrupted  link  environment.  As  the  chart  shows,  this 
data  was  collected  using  a  4MByte  file,  1400  byte  packets  and  200  Kbytes  buffers. 

Figure  4  is  essentially  the  same  as  figure  3  except  packet  size  is  512  bytes.  At  this  packet 
size  we  can  see  that  TP  performance,  even  with  congestion  control  turned  on,  is  impressively  out 
performing  TCP  even  at  good  link  BER.  In  Figure  5  the  packet  size  is  50  bytes  and  the  file  size 
is  0.5  Mbytes.  At  these  packet  sizes  TP  is  only  using  a  quarter  of  the  available  bandwidth  as 
compared  to  TCP  only  using  a  tenth  of  the  link  capacity.  With  congestion  control  turned  on,  TP 
is  only  slightly  better  that  TCP  at  low  BER.  With  or  without  congestion  control,  TP  still 
outperforms  TCP. 

5.2  Congested  Link 

When  congestion  control  is  enabled  SCPS-TP  applies  the  TCP  Vegas  congestion  control 
algorithms  to  minimize  loss  and  facilitate  the  use  of  large  windows.  In  Figure  6,  the  data  was 
collected  under  congested  link  conditions  with  congestion  control  on,  2  MBPS  link  capacity,  and 
a  4Mb  file  with  1400  byte  packets.  Because  both  TP  and  TCP  use  the  same  congestion 
algorithm,  we  expect  performance  to  be  similar  as  evidenced  by  Figure  6. 

Figure  7  is  essentially  the  same  except  a  packet  size  of  512  bytes  is  used.  Again  because 
TP  and  TCP  use  the  same  congestion  control  scheme  the  data,  as  expected,  shows  similar 
performance. 

In  Figure  8  the  data  was  collected  under  congested  link  conditions  with  congestion 
control  on,  2  MBPS  link  capacity,  and  a  0.5  Mb  file  with  50  byte  packets.  Because  both  TP  and 
TCP  use  the  same  congestion  algorithm,  we  expect  performance  to  be  similar  as  evidenced  by 
Figure  8. 
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6.0  Conclusions  and  Recommendations 


The  space  communication  environment  differs  from  the  terrestrial  (wired) 
communication  environment  in  ways  that  significantly  effect  transport  protocol  performance  and 
the  quality  of  service  to  the  user.  While  TCP  works  well  in  the  terrestrial  environment, 
modification  is  necessary  to  provide  good  performance  in  the  satellite  environment.  One  of  the 
primary  differences  between  space  communication  environments  and  current  terrestrial 
environments  is  the  source  of  data  loss.  Terrestrial  networks  primarily  experience  loss  caused  by 
congestion.  In  contrast,  space  communication  networks  exhibit  mixed  loss  characteristics. 
Losses  can  result  from  congestion,  corruption,  or  link  outages. 

TCP’s  assumption  that  virtually  all  loss  is  caused  by  congestion  results  in  severe 
degradation  of  performance  in  error-prone  wireless  environments.  When  losses  are  not  caused 
by  congestion,  SCPS-TP’s  throughput  remains  high  by  avoiding  the  congestion-control  response 
and  by  providing  enhanced  information  about  data  loss  via  the  SCPS-TP  Selective  Negative 
Acknowledgment  (SNACK)  option. 

The  test  program  has  shown  that  SCPS  provides  greatly  improved  performance  in  a 
wireless  environment  while  maintaining  performance  at  least  as  good  as  TCP  in  a  terrestrial 
(wired)  environment.  It  is  recommended  that  the  SCPS  protocol  development  be  completed  and 
software  versions  made  available  for  all  major  computer  platforms  to  support  both  commercial 
and  military  users. 
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